fix(factory): treat 404 agent_not_found on release as terminal success - #365

A `FleetClient.release()` that comes back with a Relay 404
`agent_not_found` IS the successful end state release itself aims for:
the agent is already gone from Relay's view. Treating it as a failure
re-arms `#abandonStuckDispatch` → `#releaseAndTerminateAgents` at ~1 Hz
forever. That is what wedged cloud dispatch: an instrumented `/evidence`
stream captured 1434 stderr lines in 13 minutes, 100% of them the same
three ghost agents (`ar-9-impl-sandbox`, `ar-1540-babysit-relay`,
`ar-1540-impl-relay`) cycling through:

  [factory] releasing agents held past deadline
    {issue:"9", heldForMs:373458303, holdTimeoutMs:14400000,
     waitingForTerminalState:"human-review",
     reason:"held-past-deadline",
     agents:["ar-9-impl-sandbox"]}
  [factory] no pid available to terminate ar-9-impl-sandbox during
    completion
  [factory] failed to release ar-9-impl-sandbox during completion
    {name:"RelayError", message:'Agent "ar-9-impl-sandbox" not found',
     code:"not_found", retryable:false, statusCode:404,
     rawCode:"agent_not_found"}

Sweep discovery never got a slot because every cycle was consumed by
this loop; the canary issue and every real work unit sat untouched.

The fix classifies a release error as "already gone" when either the
canonical `rawCode === 'agent_not_found'` field is set, or the fallback
combination `statusCode === 404 && code === 'not_found'` is present (a
middleware may re-throw with the HTTP status preserved but drop the
SDK-specific rawCode; the fix depends on catching both shapes). On the
already-gone path, the code performs the exact same bookkeeping the
success path does — `batch.recordRelease` and the `agent.released`
report — so the lifecycle marches on to `abandoned` and the sweep tick
frees up. Anything else keeps going through the failure path: a
retryable 503 host-unavailable, a real 5xx, an unrelated 404 on a
different resource all still add the agent to `failed`, drive
`cleanupComplete = false`, and schedule a legitimate retry.

Isolated the classifier into its own module so the reasoning lives
next to the rule and the tests are focused (rather than adding a case
to the 20k-line factory.test.ts, which already carries known flakes).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Session-Id: a4adc660-7d8a-4fff-b674-2e3931afd6cb